1. Field of the Invention
The invention relates to the transmission of multimedia contents via a communication network and more precisely to the broadcasting of multimedia contents between a content server and content receivers via a communication network adapted to broadcast multimedia contents.
2. Description of the Prior Art
Here “multimedia content” means sets of data of the same type, such as data files or videos, for example. A set of data generally constitutes what the person skilled in the art calls an ADU (Application Data Unit). For example, a set of data from a data file constitutes a segment of that file and a set of data from a video constitutes a frame of type I, B or P of a main (or base) layer or of an enhanced layer of an image from that video. In the field of broadcasting rich media contents, as they are known, the sets of data form part of an MPEG-4 stream and may constitute an interactive scene with which a user can interact (or interface). That scene is usually transmitted in parallel with the video stream “sent in streaming mode” according to the BIFS standard (Binary Format for Scenes—a binary format for two-dimensional or three-dimensional audiovisual contents based on VRML and part 11 of the MPEG4 standard). It must be remembered that a BIFS scene consists of BIFS access control units (sets of commands and presentation times) that produce a BIFS stream. Launching a BIFS stream consists in applying to the scene the modifications that are described in the BIFS commands and then displaying the result on the user's terminal. As in the case of a video, certain BIFS commands can describe an entire scene (which can then be decoded without knowing the preceding BIFS commands, like a frame of type I (in video coding)), while other commands modify the existing scene, like a frame of type P (in video coding).
Moreover, here “communication network adapted to broadcast contents” means a satellite network, such as an SDMB (Satellite Digital Multimedia Broadcast) network, for example, a terrestrial network, where appropriate of radio type, such as a UMTS network adapted to broadcasting (for example of MBMS (Multimedia Broadcast/Multimedia Services) or DVB-H (Digital Video Broadcasting-Handhelds) (mobile television) type)), or a hybrid network, i.e. a combined satellite and terrestrial network, such as a radio network of DVB-H type adapted to satellite links, for example.
As the person skilled in the art is aware, to broadcast a content, for example a video, between a content server and content receivers, the first step is to generate in the content server a continuous stream of IBP frames in the form of IP (Internet Protocol) packets. Those IP packets are then transmitted to an IP encapsulation equipment in order for it to encapsulate them in bursts conforming to the mode of transmission used, for example the TDMA (Time Division Multiple Access) mode. The bursts (containing the encapsulated packets) are then broadcast to the content receivers via the “broadcast” network so that the receivers can reconstitute the content represented by the IP packets and either store that reconstituted content temporarily with a view to subsequent use by a content player or send that reconstituted content to a content player with a view to immediate or subsequent use.
The IP encapsulation equipment generally encapsulates the IP packets that it receives from one or more content servers in successive bursts as a function of their order of arrival. The types and/or structures of the various contents represented by the IP packets generally being indistinguishable at the IP level but more generally at the port or RTP level, encapsulation is effected independently of the type and/or the structure of the content or contents at the same IP address. It is always possible to distinguish streams by their IP address, for example by sending the two layers (main and enhanced (or improved)) to two IP addresses in the same burst. Apart from this implying a constraint on the encoder and the addressing plan and therefore requiring non-negligible signaling tables, this does not improve the processing of the burst as information such as the beginning or the end is still not known and appropriate decisions therefore cannot be taken. The sole benefit lies in being able to add redundancy data (FEC data) in a differentiated manner and to effect temporal interleaving. It can therefore happen that a content is divided over a plurality of bursts separated by a relatively long time interval.
Now, in certain modes of operation of a content receiver or the associated content player, for example in the case of changing television channel, this temporal separation can lead to an increase in the time necessary for displaying a first video image. In fact, when a video receiver (or player) changes channel it must be synchronized to a new burst, then find the first valid I frame, and then display it, which generates a cumulative delay equal to the sum of the synchronization time, the time to receive the first valid I frame, and the time to decode the latter.
Similarly, when a file receiver receives a burst of data on a channel, it must be synchronized to that burst, then collect the IP packets contained in that burst, and then effect decoding of FEC (Forward Error Correction) or MPE-FEC (in the case of a DVB-H network) type of those IP packets in order to be able to correct any errors, then to be able to reconstitute the file segments that they represent, and finally to store the reconstituted segments in the form of a file. If a segment is distributed over a plurality of bursts, and it is a question of the last, or even of the only, segment of the file, it is necessary to wait for a period at least equal to the duration of a burst to be able to retrieve the segment and therefore to form the file. Moreover, if the segment creation application adds its own FEC protection to the MPE-FEC protection of the initial file, redundancy and a loss of performance result from the fact that errors must be looked for in each burst whereas error correction would be improved if it were effected over several bursts. In this case, it is therefore better not to apply the protection (error correction) at the MPE-FEC level and to restrict the protection to FEC protection at the level of the server.
It will also be noted that in radio broadcast type networks the packet error rates (PER) may be high. If the errors relate to IP packets that represent sets of data of small size (for example frames of type B), the consequences are limited. However, if the errors relate to IP packets that represent sets of data of large size (for example frames of type I), this can have the consequence of rendering unusable several other sets of received data (cascade effect on complementary frames of different types). The error correction techniques (of FEC or MPE-FEC type) being applied at the level of the IP encapsulation equipments to IP packets that do not distinguish the different sizes of the sets of data that they represent, it is not possible to vary their efficacy as a function of these size differences.
To reduce the packet error rate it is undoubtedly possible to increase the rate (or level) of error correction, but this has the consequence of increasing the amount of redundant data (known as “FEC data”) and therefore of consuming bandwidth, which is undesirable because the bandwidth is limited.
Other error rate reduction solutions may be envisaged, for example managing the end-to-end quality of service (QoS), which necessitates interactive communication between the server and the client, or analyzing in the IP encapsulation equipment the sets of data that are contained in the IP packets, which obliges the IP encapsulator to understand the semantics of the application, which is not easy for a network infrastructure equipment (increased processing even though the bit rates are high) and difficult to maintain (the software must be updated each time a new application is deployed). However, these solutions induce other drawbacks that make them difficult, or even impossible, to use, or which rule out standardization because their implementation varies from one type of server to another.
No known solution proving entirely satisfactory, the invention therefore has the object of improving on the situation.